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ABSTRACT 

The mission of the Naval Postgraduate School (NPS) is to educate, train and 
prepare officers for the 21st Century Navy (Austin, 1988). Distance learning, also 
known as distance education, remote learning or video teletraining, is defined as 
communication between an insunctor and student via some form of 
telecommunications. Distance learning has the potential to enable dramatic 
improvements in training and education by providing remote access to high-quality 
presentations. There is also a potential to multiply training and education benefits, and to 
provide savings in travel and lost time expenses. 

This thesis investigates distance learning combined with a new technology 
known as the Multicast Backbone (MBone). It documents how Dr. Richard 
Hamming’s course “Learning to Learn” was transmitted world-wide over the 
Internet’s Multicast Backbone (MBone) for an entire quarter. 

This thesis proves that the MBone is an economically feasible approach that 
works. This is the first documented attempt to provide complete course coverage 
with world-wide scope for a full academic quarter using the MBone. Specific 
lessons learned are included in an MBone user’s guide and recommendations for 


future. 
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I. INTRODUCTION 


This thesis investigates various aspects of distance learning combined with a new 
Internet technology known as the Multicast Backbone (MBone). The research revolves 
around a case study that documents the learning points derived from a successful 
worldwide Multicast of Dr. Richard Hamming’s course “Learning to Learn.” This is the 
first documented attempt to provide complete course coverage for a fid! academic quarter 
using the MBone. 

A. BACKGROUND 

1. Distance Learning 

Distance learning, also known as distance education, remote learning or 
videoteletraining, is defined as communication between an instructor and student via some 
form of telecommunications. It utilizes technology for teaching and learning situations in 
which students are geographically separated from educators, and both depend on 
electronic devices to communicate (Biggs 94). A draft Military Standard on the 
“Interoperability and Performance Standard for Video Teleconferencing” defines video 
teleconferencing (VTC) and video teletraining (VTT) as follows: 

Video teleconferencing is a two-way electronic form of communications 
that permhs two or more people in different locations to engage in face-to- 
face audio and visual co mmuni cation. Meetings, seminars, and conferences 
are conducted as if all participants are in the same room Video teletraining 
(or distance learning) is the use of teleconferencing point-to-point or multi¬ 
point to provide interactive remote site training. (MIL-STD-188-331, 93) 

Distance learning is the subject of much speculation. The Office of Naval 
Technology has conducted research in the field of distance learning with the goal of 
finding more cost-effective ways to train personnel who are geographically remote from 
training resources (Simpson, Pugh 91). In 1991, the Office ofNaval Technology 
sponsored a six-month study involving 743 Navy students to investigate the effectiveness 
and user acceptance of five instruction (Simpson, Pugh 91). This study used 
videoteletraining technologies to defiver lecture-based training, with the overall goal of 





exploring technologically cost-effective ways to train personnel who are geo^aphically 
separated from training resources. 

This goal was reached by conducting an empirical study comparing training 
effectiveness and user acceptance of live instruction and six different alternative VTT 
technologies: multichannel two-way video with two-way audio, single channel two-way 
video with two-way audio, one-way video with two-way audio, one-way video with one¬ 
way audio, one-way video with intermittent two-way audio, and audiographics (Simpson, 
Pugh 91), 

This study showed that several different forms of VTT technologies were effective, 
in terms of both student performance and student and instructor acceptance. The specific 
type of VTT technology did influence student performance and attitudes, but had a far 
smaller effect than student experience. The study also noted that the most successful VTT 
technologies were those allowing continuous two-way audio with either two-way or one¬ 
way video. And finally, student test performance was poorer with VTT systems that 
restricted remote students’ ability to converse with or see the instructor (Simpson, Pugh 
91). 

One recommendation resulting from the project was that the Chief of Naval 
Education and Training (CNET) continue efforts to refine the CNET VTT network, as 
well as analyze the feasibility and cost-effectiveness of extending the architecture of the 
CNET VTT network, using VTT technologies siich as one-way video with two-way audio 
and one-way video with one-way audio (Simpson, Pugh 91). 

Taking VTT one step further, in 1992 the Office ofNaval Technology sponsored 
another study to determine if VTT could be used to deliver hands-on training, as weU 
(Simpson, Pugh 92). Up to this point, VTT had been used for lecture-based training only. 
The results of this project showed that VTT was effective for lecture, discussion, and 
hands-on demonstration portions of training, as indicated by the final examination, student 
course evaluations, and observations. The VTT classroom design was also effective for 
hands-on training. It could serve as a model for others designing VTT classrooms for 
hands-on training. 



More recently, in 1993, the Navy Personnel and Research Development Center 
documented procedures for converting live instruction for VTT delivery. The intent was 
to make these procedures available to Navy trainers and others responsible for VTT 
dehvery (Simpson 93). 

The studies sponsored by the OfiBce of Naval Technology and performed by the 
Navy Personnel Research and Development Center have all proven that VTT can be used 
to link students and instructor across great distances. There are alternative VTT 
technologies that vary greatly in cost, so the Navy must focus on selecting the proper and 
most cost-effective VTT technologies. 

2. Multicast Backbone (MBone) 

The Multicast Backbone (MBone) originated from experiments during the 1992 
Internet Engineering Task Force (IETF) conferences in San Diego and Boston, in which 
live audio and video were transmitted around the world. The MBone currently links Unix 
workstations and has been called a ‘virtual network’ because it uses the physical Internet 
to support routing of Internet Protocol (IP) multicast packets (Casner 93). Multicasting is 
a function that allows conservation of network traffic because a sending site can ship 
audio and video packet streams that are replicated only once, even though receiving 
routers distribute the videoconference to multiple desktops (Wexler 93). For example, on 
a multicast network, a packet sent from machine A can be distributed to machines B, C, 
and D without the original packet having to be sent three times (Weiss 95). 

Because a standard audio transmission uses about 64 Kilobits per second (Kbps), 
and a default video transmission takes approximately 128 Kbps, an average worldwide 
conference will take up to about 200 Kbps of bandwidth and could even go as high as the 
global limit of 500 Kbps. This is nearly one-third of a T1 line, which is 1.5 Megabits per 
second (Mbps) and is a common site-to-site link on the Internet today. Without the 
benefit of multicast, that T1 line can be completely utilized by just three conferencing 
sessions, not even taking into account other network uses such as electronic mad, file 
transfer and Web browsing. Multicast represents a huge savings when one considers the 
amount of bandwidth that is consumed by audio and video. 
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MOTIVATION 


1. What is the Importance of Distance Learning? 

Any organization, (private industry. Government or military) faced with increasing 
costs and decreasing resources tends to push education and training down the priority list. 
Training programs may be eliminated. Educational institutions might even be forced to 
limit what is offered to students. In the United States today, many organizations are 
forced to do more with less. When it comes to education and training, distance learning 
provides an option that is economically attractive for accompUshing educational 
requirements. 

The Navy possesses a wide geographic dispersal of home ports, fleet units, and 
Navy Reserve detachments. The costs associated with transporting Navy personnel to a 
few facilities for classroom training are great. These costs include transportation, travel 
expenses, and the travel time lost from duty. In spite of these factors, there is still a 
requirement to train Navy personnel who are geographically remote from training 
resources (Simpson, Pugh 92). Effective training of personnel is essential to achieve and 
maintain national security, as well as national strategic objectives. 

Issues that have a negative effect on the ability of the Department of Defense 
(DoD) to accomplish that mission are personnel drawdowns, base closures, and reduced 
budgets. Effective training of personnel is essential. In fiscal year 1994, DoD allocated 
about $15 billion towards individual training and education (Biggs 94). Because the 
drawdowns have made it increasingly diflBcult to offer service members the opportunity to 
go on TAD, distance learning provides an economical and efiBcient solution. By importing 
an instructor via some form of telecommunication, a command can save on travel dollars 
per diem and, in most cases, registration fees. 

In the Navy, at a time when deployment schedules have become restrictive, 
distance learning allows for increased flexibility for leaders. With online course work, the 
Navy can offer classes at any time of day. As more ships, commands, and individual units 
become connected to local-area networks (LANs) and wide-area networks (WANs), 
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distance learning programs can be implemented, providing more economical avenues for 
training. 

Does distance learning work? A variety of videoconferencing and distance 
learning technologies have received considerable attention in the DoD. Those studies 
previously mentioned all reached the same conclusion and made the same 
recommendation. That is, VTT in several different forms was effective in terms of both 
student performance and student and instructor acceptance. The studies also agree that 
the Chief of Naval Education and Training should support the use and continued study of 
VTT for educating Naval personnel (Simpson, Pugh 91). 

Due to the fact that training needs for each military branch are different, difiBculty 
arises when trying to plan, prepare and implement training. Understanding when an 
approach can and ought to be employed and what benefits will be received is crucial for 
successful implementation. The following scenarios are provided as a means of 
determining when distance learning technologies may be appropriate (Wright 93): 

• Population is dispersed and cannot be economically transported to a central 
training site. 

• Students in a training group have diverse learning styles, skills, or proficiency. 

• Delivery must be closely monitored for accuracy or interpretation, 

• Students cannot be taken from job for extended periods due to mission 
requirements. 

• Live training is cost prohibitive. 

• The number of instructors with proper credentials is limited. 

The Naval Postgraduate School (NPS) has several requirements and objectives in 
the area of distance learning. Off-campus education, technology refi'esher training of NPS 
graduates, and the ability to ‘import’ an instructor without the travel costs are some of 
these requirements (Steckler, Stewart 94). 
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2. Why use the MBone? 

The MBone is a part of the Internet that is used for audio and video 
teleconferencing. It is attractive in that it works and provides real value today. The 
MBone can bring expertise over long distances and multiply training benefits. The 
development of the Internet has expanded the walls of the traditional classroom. Students 
today have access to a wealth of global information, such as remote libraries, discussion 
groups, and conaputer conferences. Students also can make connections with other 
students and with teachers around the world (Aoki, Goto 95). 

The combination of MBone resources with the concept of distance learning 
provides students and teachers with the capability of physically seeing and talking to each 
other. Just imagine the value of live video brought directly fi'om the space shuttle into 
the classroom. Think about watching scientists study the ocean floor in the Monterey Bay 
and then being able to ask them questions directly, all via a computer. These capabilities 
are currently available. 

Another expected benefit of using the MBone is be the ability to archive audio and 
video on the Internet for digital video retrieval on demand. This future work will literally 
put educators and their lectures online and open up even more possibilities for distance 
learning. It will actually bring the classroom to the student anytime it is necessary. This is 
an extremely promising area for future work. 

C. THESIS SUMMARY 

This thesis is broken into the following chapters. Chapter B discusses related 
work in the fields of distance learning and the MBone. Chapter ETI provides the reader 
with an understanding of the MBone. Chapter fV describes the principal problems 
investigated in this thesis. Chapter V documents the distance learning case study involving 
the multicast of Dr. Hamming’s class. Chapter VI summarizes the conclusions drawn 
fi-om the case study, as well as recommendations for future work. In addition, several 
appendices are provided as supplements to the thesis. Appendix A is a User’s Guide for 
accessing and using the MBone tools. Appendix B is a list of acronyms used throughout 
this thesis. Appendix C is a glossary of terms used in this thesis. 
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n. RELATED WORK 


A. BNTOODUCTION 

This chapter discusses recent work that has been conducted in the fields of 
distance learning, the multicast backbone, and network connectivity for educational 
purposes. A short summary of each study is provided to explain the study's topic and how 
it relates to this thesis. 

B. GAMBREVO: MBONE USABILITY 

This thesis looks at the choices managers face when dealing with video 
teleconferencing (Gambrino 94). In particular, this thesis focuses on the perceived 
effectiveness of the MBone fi-om a manager’s perspective. Data for this research is based 
on an NFS study with the Monterey Bay Aquarium Research Institute’s (MBARI) Internet 
conference experiment to compare the MBone versus face-to-face viewer perceptions of 
the different communication media. This study concluded that the MBone should not be 
used in communication situations involving emotional conflict, bargaining, and 
negotiation. The MBone is recommended for use in communication situations involving 
uncertainty reduction. 

C. MICE PROJECT: VIDEO ARCmVING IN EUROPE 

The Multimedia Integrated Conferencing for Europe (MICE) project has been 
piloting MBone technology in Enrope. In order to make the Hamming lecture series 
accessible to the much wider audience in Europe, the author provided copies of the lecture 
series video tapes to the major MICE National Support Centers in Europe, which then 
arranged for a remulticast of the Hamming lectmes. A further research endeavor includes 
digitizing video for media retrieval on demand. More information about the MICE center 
can found at http://www.cs.ucl.ac.uk/mice/mice.html (Handley) 

D. BIGELOW: INTERNETWORKING K-12 SCHOOLS 

This thesis documents the planning, design, and implementation of a regional, wide 
area network connecting K-12 schools, research institutions, libraries, and institutions of 







higher education throughout the Monterey Bay area of California’s central coast. It can 
be found o nlin e at http://mvw.stl.nps.navy.mil/~rjbigelo/thesis.html (Bigelow 95). 

E. STECKLER AND STEWART: DISTANCE LEARNING PLAN 
The study examined requirements and design for the development and 

implementation of a videoteletraining (VTT) system for 25 Defense Finance and 
Accounting Service (DFAS) centers. The study focuses on basic and technological issues 
regarding all aspects of VTT as they apply to DoD, including current technology, evolving 
VTT hardware and software capabihties, and compression algorithm standards (Steckler, 
Stewart 94). 

F. RETTINGER: DESKTOP VIDEO CONFERENCING 

This study looks at the various aspects of desktop video conferencing. This 
research involves an experiment that utilizes the technology of the MBone to deliver a 
week-long seminar to participants throughout North Carolina. Topics also include the 
human factors issues with desktop videoconferencing and the interactive seminar 
demonstration (Rettinger 95). 

G. DISTANCE LEARNING EFFORTS 

As the Internet connects universities and colleges all over the world, educational 
applications are widely discussed among educators and researchers. The biggest 
advantage of the Internet is its international connectivity (Aoki, Goto 95). Regionally, 
there is a research project caUed Monterey BayNet which has been internetworking K-12 
schools, colleges, universities, museums, libraries, government agencies, and research 
institutions in two California counties (Brutzman 95). The network design provides 
access to live or archived media using a variety of bandwidth rates (Brutzman 95). This 
ongoing network project gives teachers and students full access to the Internet and all the 
information that the World-Wide Web (WWW) has to offer. 

H. SIGGRAPH ‘95 “MBone UNPLUGGED” 

At a week-long graphics conference held at the Los Angeles Convention Center, a 
team of NPS students (including this author) designed and buUt a mobile MBone cart that 
used wireless networking technology in order to broadcast the events at SIGGRAPH. 



This experiment provided a more in-depth look into the details of setting up a network 
that involves MBone transmissions. It gave the team an opportumty to test the limits of 
wireless communications and raised a series of questions that have the potential to further 
the research and technology of the MBone (Brutzman, Emswiler 95). 








m. MULTICAST BACKBONE (MBone) 


A. INTRODUCTION 

Over the last decade, the personal computer (PC) has evolved from a stand-alone 
personal productivity device to a widely-connected information tool. Networked PCs are 
becoming the center of business communication. PCs are already used to send faxes and 
electronic mail (e-mail), to share databases and automate workflow, and even to hold 
long-distance meetings using unicast videoconferencing tools. The resulting boon to 
productivity is spurring strong demand for further PC-based communication applications. 
The drive to improve communication via PC is a major force behind technology 
developments in the 1990s. We expect that eventual availability of MBone tools will be a 
major event in PC evolution. 

The author has read articles that state the Multicast Backbone (MBone) is “not yet 
ready for prime time,” and has attended the Internet World conference, where a 
multimedia expert stated the MBone could not be used for distance learning. As a 
member of the NPS Information Infrastructure Research Group (URG), the author studied 
and documented the viability and impact of distance learning over the MBone. The goal 
of this work is to show that the MBone can be used for academically useful distance 
learning. Some technical considerations must be explained frrst. 

The MBone provides many-to-many network delivery services for applications 
such as videoconferencing and audio where several hosts need to communicate 
simultaneously. Because the MBone utilizes the Internet, there are no enforced 
restrictions on its use. Although this capability is impressive, it does have drawbacks. For 
example, individuals with inadequate equipment or improper training can bring down 
entire networks. If the MBone is to be considered a shared medium for distance learning, 
there must be an understanding as to the impacts and implications of doing so. This work 
demonstrates that effective global learning using the MBone is feasible. 

Multicasting has existed for several years on local area networks such as Ethernet 
and Fiber Distributed Data Interface (FDDI). However, with IP multicast addressing at 
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the network layer, group communication can be established across the Internet 
(Macedonia, Brutzman 94). Because multicasting functionality has not been integrated 
into many routers, the MBone is layered over the Internet using multicast routers (called 
mrouters), which typically are dedicated workstation-class machines. 

The MBone provides near-real-time audio and video delivery. Some time delays 
or communication failures can be expected because of network congestion. Packets of 
data that carry the audio and video signals across the network may become lost during 
transmission, causing communication dropout. These losses are a function of overall 
Internet capacity and are largely independent of the number of people subscribing to a 
given MBone session. 

B. CONSIDERATIONS 

1. Setting up an MBone Environment 

The MBone has been called a virtual network because it shares the same physical 
medium as the Internet. It uses a “tunneling” scheme to forward multicast packets among 
the islands of MBone subnets through Internet IP routers that (typically) do not support 
IP multicast (Macedonia, Brutzman 94). 

To receive multicast packets on a LAN, a system administrator will need to 
configure an mrouter. This can be either a single workstation on a LAN, or a host 
dedicated as a parallel mrouter (Macedonia, Brutzman 94). Another option is to take an 
old, unused workstation and reconfigure it as an mrouter. This process requires adding a 
second Ethernet card to the workstation so that this mrouter can act independently and in 
parallel with the standard IP router (Macedonia, Bmtzman 94). The Naval Postgraduate 
School uses both approaches. Downloading the application software tools is the next 
step. 

This discussion about connecting a site to the MBone has been brief For a 
complete set of instructions, the reader should look at the Frequently Asked Questions 
(FAQ). The MBone FAQ is a good source for system administrators wishing to establish 
an mrouter on site. It provides detailed information and instructions for downloading 



software tools and for ensuring that multicast-compatible kernels are available for target 
workstations. The FAQ can be found online at ftp://venera.isi.edu/MBone/faq.txt. 

2. What is Needed to Participate on the MBone? 

a. Hardware Requirements 

No special hardware is required to receive video on the MBone. Decoding 
and display are all done in software using an X-window display. The data rate is typically 
25 Kbps to 128 Kbps. Transmitting video requires a workstation with a frame-capture 
board and camera, typically a camcorder with a video output or built-in camera. Several 
difierent boards are supported, including Sun's Sun Video, SGFs Indigo Video, and the 
Sony NEWS frame capture board. 

To receive audio, a machine must be audio equipped such as the 
SunSparclO with an audio box, some Hewlett-Packard workstations, the SGI Indy and 
SGI Indigo. On most architectures, no hardware other than a microphone is required - 
sound I/O is via the built-in audio hardware. 

b. Software Requirements 

Software applications for use on the MBone have been developed by 
researchers on a voluntary basis. At this time the tools are free of charge and need only be 
downloaded and placed on a Unix workstation. 

c. Other Requirements 

(1) Good lighting: A desk lamp is significantly better than ofiBce lighting 
for improving image quality, especially in otherwise low light conditions with inexpensive 
cameras. 

(2) Video camera: If video is to be transmitted, a fixed focus camera that 
works well in well lit conditions is fine for the desktop. A video camera is more 
expensive, but performs better in lower light and has zoom capability. A camera is not 
required to receive or display video. 

d. Associated Costs 

Taking time to learn how to connect to and use the MBone is what usually 
poses the greatest cost. It takes approximately one to three weeks for a 
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network-knowledgeable person, working part-time, to establish the MBone at a new site 
(Macedonia, Brutzman 94). Depending on the number of users and the amount of MBone 
usage, there may also be a need for a dedicated MBone network administrator. 

Equipment cost is often relatively low. An SGI entry-level workstation 
runs between $15-$20K. The cost of video cameras ranges fi'om $50 for a simple desktop 
version to $2,000 for a high-powered piece of equipment. The MBone mailing lists 
publish up-to-date price listings on the latest equipment needed for communicating on the 
MBone. 

Another equipment cost that must be considered is bandwidth. NFS runs 
the MBone tools on workstations connected via Ethernet (10 Mbps). The off-campus 
links are via T1 lines (1.5 Mbps). NFS researchers have found that bandwidth capacities 
lower than T1 are generally unsuitable for MBone video (Macedonia, Brut zman 94). 

Some users on specially configured networks have managed to make the tools work at 56 
and 64 Kbps (Macedonia, Brutzman 94). 

3. Using the MBone Tools 

The following is a list of MBone applications available on the Unix workstations 
at the Naval Fostgraduate School. Appendix A provides detailed instructions for using 
these tools. 

(1) Session Directory fs r/l: Session Directory is the tool used to manage 
MBone sessions. It displays available sessions and can be used to create new ones. 
Sessions will be announced in the session directory window. Clicking on a session name 
gives information about the session, such as time and date of transmission. 

(2) Network Video f m /f tool : Network Video is used to transmit and 
receive slow-fi-ame-rate video. It has a default bandwidth of 128 Kbps, which provides a 
typical fi'ame rate of three to five fi^ames per second. When a session that involves video 
communications is selected fiom the session directory, a control panel appears. The panel 
consists of a menu bar, a box to show iconic versions of active video streams, and some 
number of additional panels, m allows the user to specify various options. In most cases, 
the assigned defaults are adequate. 



(3) Visual Audio Tool ( va f\ version 2.4 : Visual Audio Tool is used for 
audio teleconferences. When a session that involves audio communications is selected 
from the session directory, the vat window appears. It is not necessary to speak in order 
to participate in a conference. In fact, the normal etiquette is to wait until the speaker has 
hnished and has opened questions to the floor or to the Internet, before speaking. Using 
vat requires a certain amount of prudence to avoid accidental transmissions during 
conference sessions. 

(4) Video Conference ( vie): Video Conference is an experimental video 
conferencing tool for transmitting video over an IP Multicast network. The main vie 
window provides an abbreviated summary of all sources that are actively transmitting 
video to the conference address. If no one is transmitting video to the session, the text 
‘‘No Network Sources” is displayed in the window. 

(5) Shared whiteboard (w ft i tool : Shared whiteboard can be used as a 
shared white board drawing surface and it can be used to export and view postscript files. 
Speakers can make their slides available as postscript files during a conference session. 

The camera can be directed at the speaker while the slides are viewed via the whiteboard 
facUity. 

C. SUMMARY 

It isn’t every day that someone says to you, “Here is a multimedia television 
station that you can use to broadcast from your desktop to the world” (Macedonia, 
Brutzman 94). The MBone has changed the way people work and interact on the net. 

Today the MBone is used by thousands of researchers in collaborative efforts to 
further technology and other research efforts. Created in 1992 for group communications 
among universities and research labs, the MBone has approximately 1,800 nodes, roughly 
the same number that the Internet had in 1990. 

Many events are broadcast over the MBone, including NASA Select’s coverage of 
shuttle missions and audio sessions of the House and Senate. The November 18, 1994 
Rolling Stones concert was one the largest MBone events. There is even a “radio-station” 
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called Radio Free Vat, where any MBone participant can sign up for spots to play music 
“on the air.” 

It is the author’s opinion that the most significant of aU uses of the MBone is the 
ability to provide distance learning. There is a potential to multiply training and education 
benefits, and to provide savings in travel and lost time expenses. More important, the 
MBone is a convenient, accessible way to educate personnel all over the world. 
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rV, PROBLEM STATEMENT 


A. INTRODUCTION 

The focus of this thesis is to investigate what is required to produce an ongoing 
educational event over the Multicast Backbone (MBone). The MBone is a new 
technology, however, several questions pertain. Can the MBone sustain the bandwidth 
constraints and uncertainties associated with the Internet? Can the MBone be used for 
distance learning? If so, how is it done? 

When transmitting audio and video, it is important to achieve near-real-time 
quahty. This quality is difiScult to achieve due to the high amount of bandwidth associated 
with the two. Private networks use high-speed dedicated links, whereas the Internet is a 
shared internetwork with many thousands of users doing many different things at any 
given time (Muirden 95). Today, there are over forty commercial products for conducting 
real-time audio and video over the Internet. Two of the most widely used systems are the 
MBone tools and CU-SeeMe (Muirden 95). 

B. NAVAL POSTGRADUATE SCHOOL (NPS) GOALS 

The following mission statement is from the Naval Postgraduate School’s World 
Wide Web home page. 

The mission of the Naval Postgraduate School is to enhance the security of 
the United States of America through graduate and professional education 
programs focusing on the unique needs of the military ofiBcer. These 
programs are sustained by research and advanced studies directed towards 
the needs of the Navy and DoD. Our goals are to increase the combat 
effectiveness of the armed forces of the U. S. and its allies, and to 
contribute to fundamental scientific, engineering, policy, and operational 
advances that support the Navy, DoD, and other national security 
estabhshments (Taylor 95). 

NPS has a vision of being the world leader in defense-related graduate education 
and research by the year 2000. The intent is to provide the future leaders of the armed 
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services with the technical, analytical, and managerial skills needed to create and sustain 
eflScient, cost-effective, and fully combat-ready military forces (Taylor 95). 

NPS education will be recognized as a key ingredient in the career development of 
military officers, as a vital enhancement of their war fighting capabilities, as a critical step 
in preparing for joint and combined assignments, and as a key element leading to high level 
leadership positions (Taylor 95). 

Currently, personnel are assigned to NPS for an average tour of two years. 
Unfortunately, there is neither enough money nor time to send every officer to NPS. One 
of the five NPS guiding principles is to invest in the education, training, technology, and 
facilities needed to fulfill the mission. Because military and DoD personnel are scattered 
all around the world, it is difficult for NPS to educate those people who are unable to 
attend formal training. One potential solution to this problem is the increasing network 
connectivity within DoD and military institutions. If they do not have the technology 
today, then they are likely to in the future. With network connectivity comes the 
capability to institute a distance learning program. Although the Navy has conducted 
previous research in the area of video teletraining, what makes this research different is a 
new technical capability called the MBone. 

C. THE MUETICAST BACKBONE (MBone) 

The MBone was developed as a tool that allows researchers to communicate using 
audio and video over the Internet. Until a few years ago, people thought that the Internet 
could not support the transmission of live audio and video. Although the robustness of 
the Internet Protocol (IP) leads people to believe that the Internet caimot be broken, h 
does have its limi ts High-bandwidth applications such as audio and video are pushing 
these limits to the extreme. 

One co mm on analogy is that the Internet is like a freeway. The more cars there 
are on the road, the longer it takes to get to work. Sometimes there are accidents or 
collisions, which can cause even greater delays. As more cars are built, more cars get on 
the freeway, causing even more congestion. Every time another car gets on a busy 
freeway, it causes others to slow down. When drivers have to slow down or are even 
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forced to get off the freeway irntd another time, delays become unacceptable. Similarly, 
the Internet can take only so much traffic before quality of service becomes an issue. The 
more users are active on the Internet, the greater the chance that other users are affected. 
Therefore, the quaUty of service degrades. 

Chapter V provides a detailed look at the MBone. Appendix A explains how to 
use the MBone tools. 

D. THE CASE STUDY 

Using the MBone, an NFS course was transmitted live to the world three times a 
week. As discussed in Chapter I, audio and video take up a lot of bandwidth. 

Transferring huge amounts of bandwidth, such as the kind associated with digitized video 
and audio traffic, can bring most networking technology to a standstill. Thus, many open 
questions had to be addressed. 

The use of audio and video on the Internet is increasing (Muirden 95). Today, 
most events on the MBone are localized or special one-shot events—perhaps for one day 
at a time or for a whole week. Because the Internet currently lacks the capacity for 
everyone to multicast everywhere simultaneously, coexisting with other users on the 
Internet using both audio and video on a regular production basis has not previously been 
attempted. 

This case study consisted of broadcasting a total of 31 lectures from Dr. Richard 
Ha mmin g’s course “Learning to Learn” over an entire academic quarter. By conducting 
this smdy, the author attempted to prove that the MBone can sustain the impact of an 
ongoing event, and remote participants would receive Dr. Hamming’s class on schedule. 

This project presented two obstacles. The first is a technical issue. The Internet 
can handle only so much bandwidth before signal quality begins to degrade. The remote 
participants must be able to understand what the instructor is saying. When numerous 
users utilize the MBone, the Internet connections can become bogged down, producing 
terrible signal quahty or maybe no signal at aU. 

The second obstacle deals with human issues relating to a shared resource. Global 
MBone bandwidth is estimated at only 500 Kbps. A site wishing to broadcast a special 
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event might find itself limited by another site’s existing event. To try to alleviate any 
problems that might occur, the author announced the plan to broadcast the course and the 
willingness to make schedule adjustments, when necessary. Chapter V describes the case 
study in detail. 

E. SUMMARY 

The goal of this thesis was to prove that the MBone can sustain the bandwidth 
constraints and uncertainties associated with the Internet. Due to the large amounts of 
bandwidth consumed by audio and video, and the problems that exist with a shared 
network, it is difficult to achieve a signal quality that is acceptable enough for distance 
learning. 

The case study demonstrated that distance learning over the Internet will work. 
The research in this thesis apphes a new technical capability called the MBone to the 
Naval Postgraduate School goals of providing distance learning and can be utilized to 
expand the role of NPS in a much more economical way. 



V. THE HAMMING MULTICAST 


A. EVmODUCTION 

The purpose of this research was to test the MBone’s ability to sustain an ongoing 
event for use in the field of distance learning. Live audio and video of a course taught at 
the Naval Postgraduate School (NPS) were sent to participants world-wide three times 
per week for a full academic quarter. The objective of this research was to “push back the 
envelope” regarding the kinds of programming that are possible on the MBone. The 
course was transmitted on a global channel to test the ability of transmitting for an 
extended period of time—in this case, for eleven weeks. The goal was to learn some new 
lessons and to then distribute both results and recommendations to the MBone 
co mmuni ty This effort involved finding a location with suitable attributes for an MBone 
broadcast, providing network connectivity, installing and connecting necessary equipment, 
and finding an instructor who would agree to be part of an Internet first and was willing to 
be taped while lecturing to the world. This chapter describes how each of these efforts 
was accomplished and why certain decisions were made. It also provides detailed 
accounts of the problems that occurred. 

B. PRODUCTION REQUIREMENTS 

The first step was finding a location to meet the network, electrical, and acoustical 
requirements. The room also needed to be large enough to hold a class of about 60-75 
students. Initially, a number of locations on campus appeared to possess the physical 
characteristics necessary to broadcast a course over the MBone. They were the 
auditoriums in Glasgow and Ingersoll Halls, various classrooms in Spanagel Hall, and the 
newly constructed auditorium next to Melville Hall. However, numerous difficulties 
emerged: 

The Glasgow auditorium (room 109) had an audio visual projection room and was 
large enough for the expected number of students. However, its acoustics were 
inadequate. The auditorium in Ingersoll (room 122) had an audio visual projection room, 
excellent acoustics, and enough room for about 100 students. However, Ingersoll 122 is 
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used for a number of conferences which hold a higher priority. If a scheduling conflict 
were to arise, the class would have to relocate for that period of time. Spanagel Hall had 
a number of rooms that were large enough and that had good acoustics, but none of them 
had audio visual capabilities. The equipment used for the multicast would have to be 
moved in and out of the classroom three times a week. This would take a lot more work 
and had a great potential for equipment problems to occur. The auditorium by Melville 
HaU had the best acoustics, excellent lighting conditions, would hold close to 100 
students, and had an audio visual projection booth. However, it lacked network 
connections and equipment in the booth, and the building itself was stiU under 
construction and would not be finished by the beginning of quarter. After careful 
consideration of all options, the author chose the new auditorium by Melville Hall as the 
most suitable location. 

The following section discusses the measures taken to prepare the auditorium to 
be an MBone distance learning environment. 

1. Network Setup 

The top priority was network connectivity. NFS employees, along with an outside 
contractor, installed a fiber to Ethernet adapter in the projection booth. The MBone 
tunnel was successfully configured to include the appropriate LAN, and it tested out 
satisfactorily. 

2. Hardware/Software 

A Silicon Graphics Inc. (SGI) Indy workstation was set up in the AV booth of the 
auditorium. The MBone software tools and an electronic mail tool were loaded on the 
Indy. Currently, there are no monitoring tools for the MBone. As a result, the only way 
to receive imm ediate feedback about the quality of a signal at some remote site is via e- 
mail. E-mail was monitored through a telnet window. 

All classes were broadcast with audio and video. The announcement appeared in 
the Session Directory (sd) under “Hamming; Learning to Learn.” This session was 
created at the beginning of the quarter and remained there until the end. The scope of the 
sessions was set to ttl = 127, global transmission. Video was transmitted using Network 
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Video (nv) for maxunum compatibility with remote users. The bandwidth was kept at the 
default of 128 Kbps. Audio was transmitted using Visual Audio Tool (vat). The default 
audio input was changed from microphone mode to line-in mode. The gain level slider 
was adjusted as required during each lecture, and adjustments to the scope and bandwidth 
were made when scheduling conflicts arose. 

Under the Menu button from vat. Lecture Mode was selected over the default 
Conference Mode because this was a noninteractive session, and Lecture Mode results in 
a better quality signal. The Silence Suppress was also turned off, allowing the 
transmitting site to keep the focus of the audio session and making it difficult for other 
sites to send audio on that session. The User’s Guide for the MBone b Appendix A 
provides a more detailed description of the MBone software tools and setup selections. 

3. Audio Visual Setup 

The basic audio visual requirements are known: a standard video camera with a 
tripod, a TV monitor, and a VCR which was used to tape each lecture while it was being 
broadcast. Because the audio visual booth was in a separate room inside the auditorium, 
audio was provided using a wireless microphone given to the professor before each 
lecture. No attempt was made to include the MBone audiencejs) in the audio portion of 
the lectures. Taking questions from the network required a sound system for the 
auditorium (so the NFS audience could hear the questions). Since this capability was not 
part of the research at the time, questions were taken via e-maU. 

The professor’s requirements were unknown. If computer-generated video were 
used, it would have to be scan-converted to NTSC (National Television Standards 
Committee). If traditional overhead slides were used, the best way to pipe them into the 
MBone would have to be determined. Another consideration was that video projection 
causes lighting problems if there are cameras in the room. 

Once requirements were properly identified, personnel from the NFS AV 
department worked several hours to set up the equipment in the projection booth. After 
the first day of testing, the camera was inadvertently left on overnight. As a result, it 
overheated and failed. After the camera was replaced, all of the wiring had to be redone. 
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Audio/video checks for both MBone and the VCR were then satisfactory. To prevent 
errors such as the one mentioned above, the following checklist, covering everything from 
the equipment to the building itselfr was created: 

(1) Room 

- Lights => All on except light above board & light in booth 

- Doors => Close auditorium doors when class begins 

- Lectern => Is it still there? 

- Markers/Erasers => Only black & red for maximum contrast 

- Close door to projection booth 

- Erase board after lecture 

- Lock doors when finished 

(2) Video/Audio Equipment 

- Power button on top of camera 

- Lens cap ofiF 

- Turn on TV 

- Turn on VCR 

- Put in new tape/cue tape 

“ Ensure only two lectures/tape 
— Label tapes with title, lecture number and date 

- Set record speed to SP for best quality 

- Start recording ~ 3 minutes prior to actual start 

- Turn on wireless microphone and test 

(3) Workstation 

- Login 

- Open session directory (scf) via console 

- Open Hamming session from sd menu 

- Set audio panel MENU to the following: 
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silence suppress 


- lecture mode 

- Change the microphone icon to digital input 

- Select “Keep Audio” to ensure this is active session 

- Video panel: Verily bandwidth: 128 Kbps 

(4) Important Phone Numbers List Handy 

(5) Network Monitoring Tools 

- Etherview => /usr/etc/etherview -g 


C. COURSE INFORMATION 

Dr. Richard Hamming accepted the request to participate in this world-wide 
experiment. Dr. Hamming received a Ph.D. in Mathematics from the University of Illinois 
in 1942. He worked at Los Alamos from 1945 to 1946, at Bell Laboratories from 1946 to 
1976, served three years at Princeton University as an Adjunct Professor of Statistics, and 
joined the Naval Postgraduate School in 1976. Dr. Hamming is a past president of the 
Association for Computing Machinery (ACM) and recipient of the Turing Prize of the 
ACM. He is both namesake and a recipient of the IEEE RW. Hamming medal and has 
received a large variety of other awards. Dr. Hamming is the author of numerous papers 
and books. 

The name of his course is ‘The Art of Doing Science and Engineering: Learning 
to Learn.” It is often referred to as “Hamming on Hamming” due to the fact that Dr. 
Hamming’s work began or greatly influenced many of the subject areas covered in his 
course. Topics include: foundations of the digital (discrete) revolution, foundations of 
computer hardware/software/apphcations; limits of computer appUcations and artificial 
intelligence (AI); N-dimensional space, coding theory, error correcting codes, information 
theory, digital filters, simulation, fiber optics, computer-aided instruction (CAI), 
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mathematics, quantum mechanics, creativity, experts, unreliable data, and systems 
engineering. Dr. Hamming has written about his course: 


I win examine, criticize and display styles of thinking. To illustrate the points 
of style I will often use technical knowledge that most of you know. ... You 
should regard this as a course that complements the many technical courses 
you have learned. Many of the things I will talk about are things that I beUeve 
you ought to know but which simply do not fit into courses in the standard 
curriculum. . . The course is concerned with ‘style,’ and almost by definition 
style caimot be taught in the normal mann er by using words. I can otdy 
approach the topic through particular examples, which I hope are well within 
your grasp, though the examples come mainly fi^om my 30 years in the 
mathematics department of the Research Division of the Bell Telephone 
Laboratories, (before it was broken up). It also comes fi^om years of study of 
the work of others. (Hamming 95) 

D, RESULTS 

1. Findings 

Classes were held Tuesdays and Thursdays fi-om 1210-1300 Pacific (1910-2000 
GMT) and Fridays fi-om 1410-1500 Pacific (2110-2200 GMT). A total of 31 lectures 
were broadcast between March 28 and June 6, 1995. Observations were made and are 
documented in the following sections. The findings are broken up into these categories: 
Camera Work, Audio Issues, Scheduling Issues, Statistical Information, Room Issues, and 
Miscellaneous Findings. 

a. Camera Work 

The first day of class, the author met with Dr. Hamming to go over 
procedures for the multicast. Dr. Hamming warned that he walked around quite a bit, so 
camera work might be tricky. He also requested that the students in the classroom be 
included in the broadcast as well. Dr. Hamming felt the remote viewers might become 
bored with seeing only his face. He also requested there be a clock and a lectern in the 
room. 

During these broadcasts, the author observed the lectures from the video 
camera, video monitor, and SGI workstation inside the AV booth of the auditorium. 
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Being on the receiving end of an MBone broadcast allowed the author to make some 
interesting observations. First, traditional video taping, with constant movement of the 
camera, is not appropriate for MBone transmissions. Because of the slow frame rates 
associated with MBone transmissions, a lot of camera movement will generally cause 
image loss, causing the viewer to miss out on certain elements of a presentation. As the 
speaker moves around, it works best to pan back and hold the image of the instructor as 
he/she moves around the room Sometimes it is easier for remote viewers to understand a 
lecture if close-ups of the speaker are filmed as he/she is standing at a lectern or in one 
position for awhile. An alternative is having a second camera on hand. The ability to 
switch between cameras opens up a new angle for producing a more professional-looking 
show. 

When video taping information, equations, etc., from a chalkboard or dry 
eraser board, it is best to put the camera on the information and hold it for at least three to 
four seconds. Holding the camera steady gives the image a chance to fully update and 
provides remote viewers a chance to focus on the information. Moving the camera back 
and forth only results in lost data. 

Another observation was that red and black markers were the only ones 
that could be seen on the MBone. The camera had a difficult time focusing on blue ones. 

b. Scheduling Issues 

The “Hamming” lecture series was announced prior to the first broadcast. 
Because MBone audio and video sessions can consume a large amount ofbandwidth, 
users should attempt to minimize the effect of MBone traffic on other users of the 
network. For example, for an entire week in April 1995, the World-Wide Web (WWW) 
conference in Germany was also being multicast over the MBone. As a result, the 
Hamming classes were broadcast five only in the local area with a ttl = 16. Later in the 
afternoon, around 4pm, the recorded version of the lectures was then rebroadcast world¬ 
wide with a ttl = 127. Changes such as these must be announced ahead of time to ensure 
that off-campus participants could arrange their schedules accordingly. Interestingly 
enough, there were more listeners during that week than at any other time. The 4pm PST 
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broadcast must have fit into everyone’s schedule better and remote viewers were already 
online fi-om the WWW conference. 

c. Audio Issues 

As previously stated, since the equipment used for the MBone multicast 
was located inside the booth of the auditorium, it was necessary to put a wireless 
microphone on Dr. Hamming before each lecture. Finding the perfect location on Dr. 
Hamming’s tie was important. Placing the microphone too high resulted in a lot of noise 
in the signal. Too low and it became diffi cult to hear him Keeping the volume up on the 
TV was a good way to tell if the volume was working. The audio signal should be tested 
before beginning transmission. Sometimes, a weak signal just meant the battery was 
running down, so a supply of spare batteries was kept handy. 

Dr. Hamming’s lectures, with the exception of one, were just that— 
lectures. Students did not ask questions and rarely challenged his ideas. A different 
format would have been more difficult for the researchers because the students' questions 
could have been heard only if Dr. Hamming took off the wireless microphone and passed 
it around. The exception to this format was a lecture intentionally designed to provoke 
interaction among the students. The lecture was titled, “Can machines think?’’ Dr. 
Hamming asked his students to come to class prepared with thought-out responses to this 
question. He also required the students to sit in the fi^ont two rows of the auditorium; 
thus, the camera work was easier to perform. In order to hear every student’s response. 
Dr. Hanaming passed around the wireless microphone. For the most part, this worked; 
however. Dr. Ha mmin g, sometimes forgot that he was no longer wearing the microphone, 
and some of his conversation was never heard. A better alternative is to have two 
microphones, a lapel microphone for the speaker and a hand-held microphone that the 
students could pass around. 

d. Miscellaneous Findings 

Although the auditorium was in a brand new building, it had problems. 

The remote controlled blinds weren’t working, so it was difficult to tape the students who 
were in line with the windows. Also, since the AV booth was painted white and contained 



two large windows, there was some glare in the camera signal. The author recommends 
the walls be painted black and the windows be covered with some black curtains to cut 
down the glare. 

2. Problems Encountered 

During the quarter, only one major problem occurred, but, unfortunately, it lasted 
for a week until a team of NPS personnel finally discovered the cause. During the week of 
May 1-5, the transmission experienced 50 percent losses at the transmitting workstation 
located inside the AV booth of the auditorium. This first occurred on a Friday afternoon, 
when was no one was around to solve the problem. During the next lecture, there was 
again a packet loss of 50 percent, surprising since there were no other significant 
processes running on that machine. The systems administrator was contacted about the 
problem. Thinking the problem was local with the transmitting workstation, the author 
rebooted the machine. That did not fix the problem Packet loss on the local machine 
usually means there are problems with the local area network (LAN). So, a previously 
created NPS session was opened and tested. There were no losses on that session. One 
theory was that there was a host on the MBone sending the ‘Ha mmin g’ machine a 
constant message to stop sending. 

A variety of experiments and network tests gave conflicting indications. Finally, 
the system administrator loaded a copy of “Etherview” on the “Ha mmin g” machine. 
Etherview is a public-domain network visualizer program with a graphical display (Hull 
91). It provides a detailed look at network traflfic which finally permitted the problem to 
be discovered. By filtering out TCP and UDP traffic, it was discovered that the NPS 
mainfr ame {vmJ.cc.nps.navy.mil, 131.120.50.50) was sending a constant stream of 
Internet Control Management Protocol (ICMP) packets to the transmitting workstation. 
Apparently, the mainframe had faulty code which did not understand multicast. Every 
time the “Hamming” machine sent a multicast packet, vmJ would send back a “check” 
message provoking the 50 percent loss at the source. The difficulty happened only for 
streams originating within NPS with ttl > 16. This problem lasted for an entire week. 
Fortunately, it did not affect others out there wishing to transmit. The answer was not 
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easy to find, even for the system administrators. Dropping the MBone tunnel that 
connected the faulty mainfi-ame removed the problem. 

Recommendation: have a graphical tool like Etherview continuously available for 
any serious multicasting. The diagnosis capabilities are essential. Other tools, such as 
tcpdump, also work if time is made to leam the syntax. Root permission is required to run 
these tools, so preparation that includes the system administrator is also necessary. The 
problem the researchers encountered is a good example of how volatile the MBone can 
be. Because the MBone is experimental, keeping in touch with the MBone community via 
the MBone mail list is always a good idea. There are others out there willing to help with 
troubleshooting. Network monitoring is a good area for future work. 

3. Feedback from Viewers 
a. Who Watched? 

The goal of the research project was to find out if an ongoing event could 
take place on the MBone. Feedback via e-mail fi'om remote participants was the only 
indication of whether or not the project was successful. Some people responded 
immediately, sometimes even during a lecture if they were experiencing difficulties— audio 
not getting through, for example. Other feedback was via the vat name window. 

On average, there were ten listeners per lecture, and sometimes as few as 
three and as many as 33. Of these numbers, five of the participants were almost always 
listening. Often, a number of remote participants would join in the session, stay for a few 
minutes, and then exit. Events on the MBone are similar to those of a TV station. 

Viewers scan through various sessions to see if there are one or two that appear 
interesting enough to keep them on the line. The following is a snapshot of a remote 
audience for the lecture held on April 25, 1995. Most of these participants remained 
‘tuned in’ for the entire lecture, perhaps because they considered the lecture material 
important, the signal quality was acceptable enough for users to understand the material, 
and, finally, there may not have been any other events occurring at that time. 
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mccaim@merak. cc. np s.navy. 120.53.5*] 

root@priiice.proteon.com [128.185.37.49] 

Gorm Haug Eriksen, Univ. of Oslo, Norway [129.240.200.192] 
Teije Vemly (teijeve@usit.uio.no) [129.240.200.25] 

Eric Klinker (NRL) [132.250.198.17] 
visio@cismmedia.univ-lyon 1 .fr [ 134.214.180.2] 
gb@darmok.cs.utali.edu [155.99.208.1] 
hamming.me.nps.navy.mil [ 131.120.151.59] 
brutzman@nps.navy.mil (fletch.stl...) [131.120.63.31] 

Don Merritt (ARE) [128.63.58.52] 

Larry Blunk (Merit) [198.108.60.101] 

Marc Michelsen (Univ ofWash - Seattle) [128.95.176.121] 
Steve Casner (ISI) [128.9.160.100] 
hudson@coast.usw.nps.navy. mil [ 131.120.62.8] 
hopper@empyrean.ucsd.edu [132.239.51.61] 
test@mcast [132.197.160.10] 
enm@sgi 10.hep.anl.gov [ 146.139.180.11 ] 
chas@volt.nrl.navy.mil [132.250.110.120] 

Joe Macker (NRL) [132.250.92.160] 

Dan Molinelli (TRW.COM) [129.4.53.11] 
deba@keUer.lbl.gov [128.3.196.47] 

Bob Braden (ISI) [128.9.160.148] 
mchugh@zetar.cs.pdx.edu [131.252.21.203] 
daasch@crueUa.ee.pdx.edu [131.252.10.177] 
beattie@grifiy.lbl.gov [128.3.196.33] 
daniel@fra.isi.edu [128.9.160.58] 
berson@mex.isi.edu [128.9.160.150] 
jfs@golum.hrb.com [149.145.2.98] 
topolcic@PEREGRINE.BBN.COM [128.89.6.129] 
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trac@ourms.nps.navy.niil [ 131.120.57.47] 
elbert@elbert.ameslab.gov [147.155.30.3] 
williams@canopus.cc.nps.navy.mil [131.120.143.126] 

Ron Broersma (NRaD, San Etiego) [128.49.192.11] 

b. Quality of Audio and Video 

Audio is the most important part of a video teleconference. Our 
experience has shown that audio is always a bigger challenge than video. Human 
cognitive abilities allow us to fill in the blanks. As stated earlier, camera work can have a 
serious effect on what remote participants see. However, if the camera is following Dr. 
Hamming walking back and forth as he lectures, it doesn’t really matter if the viewer 
misses a frame or two. It is clear that Dr. Hamming is walking back and forth. However, 
if packets of audio drop out, the problem is far more serious. It is not as easy to fill in 
those blanks, especially if the viewer is unfamihar with the subject area. 

For the most part, the quality of the audio and video signals were good. At 
the beginning of the quarter there was a zero percent audio loss, and fi'om then on a steady 
three percent loss appeared. For two lectures, a 30 percent audio loss was reported 
across the NPS campus. Nothing was reported fi'om areas outside NFS. Without remote 
participant feedback, there was no way to determine exactly what was happening on the 
other end of the broadcast. Steady attendance leads us to believe that remote signal 
quality was adequate for most sections of the MBone. 

c. Suggestions 

When broadcasting on a global chaimel, announcements should be made 
either in local time (if they are scheduled according to local time) or in GMT (if they are 
scheduled in GMT). A handy time converter exists and can be found online at 
http://hibp.ecse.rpi.edu/cgi-bin/tzconvert (Stewart 95). 

There was some concern from one overseas participant about even having 
the capability to receive such a broadcast. How do those people who cannot effectively 
participate due to bandwidth limitations participate? What is the point of trying to educate 
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if the students cannot hear the instructor? The idea was expressed that, until more 
bandwidth is made available, distance education on a global basis using the MBone will, 
unfortunately, remain very limited. 

In response to this concern, a group from the London College known as 
the Multimedia Integrated Conferencing for Europe (MICE) offered to rebroadcast the 
lectures over a European channel only (Handley). Copies of the original lecture tapes 
were made and sent to MICE, which has not only been rebroadcasting the lectures, but 
also has been working on a collaborative plan to digitize the tapes and archive them on the 
World Wide Web. 

Scheduling events is very in^ortant, especially if they are to be transmitted 
on a global chaimel. Events can be announced by sending a message to the MBone 
mailing list called rem-conf@es.net and also by using the online MBone Global Agenda 
located at http://www.cilea.it/MBone/ageruia.html. 

4. Dr. Hamming’s Comments 

Dr. Hamming beUeves that to prepare for the future, students need to forge then- 
own style and create their own vision. ‘1 have my feet planted in a prior generation. I 
want the students to question me and think for themselves,” stated Hamming. 

Is distance learning a door to the future of education? Dr. Hamming says “yes and 
no.” Although there have been studies documenting the effectiveness of distance learning, 
Dr. Ha mmin g feels there is something about a live human being which does not seem to 
get through the distance learning medium. There is an aspect of group behavior that has a 
different affect on a classroom full of students versus a single student “tuning in” to a 
lecture. 

Another dubious element of distance learning is the viewing mode of the student. 
Watching television, for example, puts one into a passive mode of viewing. Dr. Hamming 
feels the same thing happens to a student learning from a computer monitor. The student 
learns in a more passive manner and tends not to argue or debate with the instructor. 
Something is lost from the learning process. Dr. Hamming is quick to note that, although 
he cannot say what that “something” is, distance learning is better than nothing. As long 
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as course requirements are met, a remote student should receive credit. It’s just a matter 
of learning and being taught. “What you learn from others you could use to follow, what 
you learn for yourself you can use to lead,” stated Hamming. 

One of the purposes of a class is to force regular attendance; otherwise the 
learning is postponed. Without the actual requirement to be there, it becomes too easy to 
do other things at the same time or even stop listening altogether. Also, when a student is 
required to attend a class, there seems to be more put into it ahead of time. The student 
tends to mentally prepare himself for the lecture. There are fewer distractions in a 
classroom to hinder the learning process. 

When asked if this research affected his teaching style or lecture material. Dr. 
Hamming said he had to make adjustments in both areas. Noting that the first lecture is 
always the hardest in any teaching situation. Dr. Ha mmin g said that he was able to relax 
and ignore the cameras after the first couple of lectures. It did not bother him that his 
lectures were going out live over the Internet. He could not afford to let it. He simply 
adopted a “so what?” attitude. 

One habit did change sUghtly. His normal teaching routine involves walking into 
the classroom, talking to one or two students and then beginning his lecture. During this 
research project he arrived early to each lecture to get ‘wired’ for audio, and would then 
sit quietly in the auditorium to prepare his thoughts. He also made a change in his lecture 
material. Because the lectures would be going out over the Internet, he eliminated 
portions that dealt with the military aspects of students’ experiences. 

It was noted that there was very little student interaction during the quarter. The 
author thought the students might be inhibited because of the live broadcast, but Dr. 
Hamming stated that Uttle discussion is typical when the class is so large. His average 
class size is 60-70 students. A lack of student feedback concerning the research project 
prevents a clear understanding of this issue. If he could, he would limi t the number of 
students and force more class interaction. 

When asked his opinion regarding the types of courses that would work well using 
distance learning, he felt that it wasn’t a question of a good course versus a bad one. The 
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question that should be asked is, “What’s the alternative?” Is a lecture on art eliminated 
from a distance learning program because looking at the pictures over a computer screen 
wouldn’t be as good as being there? Would those remote students have the opportunity 
to ever see those pictures again? For Dr. Hamming’s class, a class of 30 might be better 
than a class of 60, but would the benefits of a smaller class outweigh the loss to students 
who are refused enrollment? The ideal situation would be one instructor for every 
student, but clearly this is unrealistic. Distance learning, though not ideal, has value. 

Dr. Ha mmin g has been completely supportive throughout this effort. He even 
repeated a lecture without benefit of audience when a recording mistake ruined a tape. It 
is difficult to imagine anyone not being challenged by Dr. Richard Ha mmin g’s ideas. 

5. Things to Consider 

Being on the receiving end of an MBone multicast, the author was able to make 
some interesting observations. First, even slow frame rate video seems to add value to 
the conference. The frame rates experienced with this research project were usually in the 
range of 0.2-5 frames per second. Even so, video still seemed to create a sense of 
presence and give visual clues. Second, it can be valuable to be able to do other things at 
the workstation while receiving a broadcast. For instance, it could be useful to look up 
some additional information by telnetting to the library or bringing up a page in a web 
browser. However, being at the desktop work space can also be a disadvantage. 
Distractions such as phone calls and e-mail can divert attention away from the multicast. 

E. SUMMARY 

This distance learning case study was delivered using the Internet’s MBone. The 
requirements necessary to conduct this study included finding a suitable location, ensuring 
network cormectivity, installing equipment and finding a flexible instructor to teach the 
course. The findings in this study proved that the MBone is a viable asset for distance 
learning. A number of questions were raised throughout the quarter leading to a better 
understanding of the MBone and the concepts of distance learning. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


A. RESEARCH CONCLUSIONS 

The Hamming case study provided the opportunity to examine the use of the 
MBone as a distance learning medium for global use. This project was successful. It 
disproves earlier beliefs that the MBone is unable to sustain an ongoing event. The goal 
was to prove that the MBone could sustain an ongoing event. Of the 31 lectures, 25 went 
out live as scheduled. Due to a scheduling conflict with the World Wide Web conference, 
three lectures had to be retransmitted on a global channel, at a later time in the day. The 
other three lectures went out one week late because of a network problem at the 
transmitting site. The symptoms for this particular problem as well as the solution have 
been documented so that in the future, an entire week of transmitting time will not be lost. 

Over the course of the quarter, there were an average of ten hsteners per lecture. 
Some provided feedback, enabling the author to leam about the quahty of the broadcast. 
The results of the study would be more useful if more remote participants had provided 
feedback. As a result, speculation is the only available tool for determining the perceived 
signal quality of remote participants. 

The MBone uses bandwidth efiSciently which makes it a strong candidate for large 
distributed presentations. Because the MBone utilizes the Internet, using adequate 
equipment and providing proper training will reduce problems associated with shared 
networking. This work demonstrates that effective global learning using the MBone is 
feasible. It also shows how commands can save on travel and training expenses for 
persoimel. 

The downside of this new technical capability is that it takes a lot of time and 
effort to leam and effectively use. It also takes some attention to technical details so it 
was important to document those lessons in passing. This is a hi-tech, experimental tool 
that is not well understood. As a result of this thesis, capabilities that were once thought 
impossible are now available. 
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B. RECOMMENDATIONS FOR FUTURE WORK 

The ability to use the MBone for an ongoing educational project such as distance 
learning is remarkable. However, as already stated, there are problems that arise when 
utilizing a shared network, especially one as large as the Internet. It would save time and 
increase usability if the nature and location of these problems could be determined as they 
happen. Currently, users rely on other user feedback. This system only alerts the sender 
of a problem, it doesn’t solve it. There is a need for monitoring tools that will help 
determine the quality of signals received at other locations. 

Another recommendation for further distance learning research using the MBone is 
to attempt an interactive course on a global scale, possibly using 2-3 different military 
commands from different parts of the United States. Better statistical information can be 
drawn from such a study to provide a deeper look into the audio endurance of the MBone 
and help find out the perceived effectiveness of the MBone as a distance learning tool. 

Finally, with the ability to view audio and video over the Internet comes the desire 
to archive that same information. Learning how to digitize these large amounts of data 
and store them in the most efficient way is important. “Putting it on the Web” provides 
even more flexibility. It allows students to view courses at a time that is more convenient. 
It gives instructors an avenue for teaching more students. One can build an educational 
video library for media on demand at almost zero dollar cost. 


APPENDIX A: MBone USER’S GUIDE 

A. INTRODUCTION 

This user’s guide is designed to assist personnel at the Naval Postgraduate School 
using the Multicast Backbone (MBone) for desktop conferencing. There are no instructions 
here on connecting a site to the MBone. To determine if a site does support the MBone, just 
ask the local network support people. Information on how to connect to the MBone can he 
found in the MBone Frequently Asked Questions (Casner 93) list, or Dan's Quick and Dirty 
Guide to Getting Connected to the MBone (Mosedale 94). Section J contains a complete 
Usting of MBone resources. 

B. OVERVIEW OF THE MBone 

The Multicast Backbone (MBone) originated from experiments during the 1992 
Internet Engineering Task Force (IETF) conferences in San Diego and Boston in which live 
audio and video were transmitted around the world. The MBone currently links Unix 
workstations and has been called a ‘virtual network’ because it uses the physical Internet to 
support routing of Internet Protocol (IP) multicast packets. On a multicast network, a packet 
can be sent once from machine A and distributed to machines B, C and D without having to 
send the original packet three times. 

C. USING THE MBone TOOLS 

The startup file for the MBone tools (called .sd.tcl) contains default audio and video 
apphcation addresses. To change these applications you must see your local support office. 
The following is a list of MBone applications available on the Unix workstations at the Naval 
Postgraduate School. 

1. Session Directory (s cCr. Session Directory is the tool used to manage MBone 
sessions. It displays available sessions and can be used to create new ones. To use the 
MBone tools simply type sd at the shell prompt. Sessions will be announced in the session 
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toectory window as shown in figure 1. Clicking on a session name gives information about 
the session such as time and date of transmission. To participate in a session press the Open 
button or double-click on the session entry. 
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Figure 1 Session Directory (r</) 


Figure 2. New Session Directory (sd) 
window 


A new sd session can be created by pressing the New button. (DO NOT CREATE 
A NEW SESSION BEFORE READING THIS GUIDE) This causes the New session popup 
window to appear (see figure 2). In the Name block, fill in the title of your session. For the 
mandatory Description, be sure to list any important instructions and associated web pages. 
Do not finish the Description with a URL since sd will append a period and interfere with 
autonoatic launch ofNetscape/Mosaic. Unused Address, Pott and RTP channel ID numbers 
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are automatically selected by session directory but these values can be manually changed if 
desired. The Scope or time-to-live range (ttl) determines how far your session will travel. 
For example a tt! of 16 would just go out across the NFS campus whereas a ttl of 127 is 
world-wide. DO NOT USE TTL=\21 WITHOUT FIRST GETTING CONSENSUS WITH 
REM-CONF@ES.NET MAIL LIST. The Lifetime block is where you determine how long 
session directory will announce your session. Also, other media such as Audio, Video and 
Whiteboard can be associated with a session. It is important to create new sessions without 
error since editing a current session can create dupUcates instead of replacements. 

The Edit button allows you to make changes in your session. The Delete button will 
remove your session and Quit will exit sd. 

The software for session directory was written at LBL by Van Jacobson and is 
available fi'om ftp://ftp.ee.lbl.gov:/conferencing/sd/ 

2. Network Video ( n v) tool : Used to transmit and receive slow frame rate video. 
When a session that involves video communications is selected from the session directory, a 
control panel appears (see figure 3). It consists of a menu bar, a box to show iconic versions 
of active video streams, and some number of additional panels, nv allows you to specify 
various options. In most cases, the assigned defaults work just fine. 

(1) Menu Bar 

The Info menu lets you see the version of nv you have. The Grabbers 
menu lets you select among available grabbers. Grabbers which are supported but not 
available on the local host are grayed out. The Encodings menu lets you select which video 
encoding to use when transmitting. The Panels menu allows you to toggle on and off the 
presence of each additional panel. The Conference Info panel contains conference address 
information, as well as a place to set your name. Each of these fields may be edited - changes 
take affect when <Retum> is pressed in a field. 
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Figure 3. nvTool 

(2) Control Panel Options 

The maxinium bandwidth limit is 1024 Kbps. The default bandwidth 
is 128 Kbps. Frame rates of 3-5 frames per second are typical for the default bandwidth of 
128 Kbps. Some systems will support higher frame rates if the bandwidth is raised or smaller 
images are sent. 

(3) Video Icon 

The Video icon box shows a small video image with a name 
underneath for each video stream it receives. Clicking on that video icon will display a larger 
video image for that source (see figure 4). 

Clicking on the larger video image will display an extra control panel 
which allows you to adjust the Brightness and Contrast of the image (see figure 5). The 
brightness and contrast parameters range from 0 to 100. The defaults are set at 60 and rarely 
need adjustment. The display size for incoming video windows can be set to half normal, or 
double the original size. 
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The control panel also displays the source address of the sender, the video format, the 
incoming and displayed frame rate, the incoming bandwidth, and a running average value for 
network loss. Other controls include a set of size buttons, a switch to view the video as either 
Grayscale or Color (if color is being sent), and a button which allows you to Capture the 
current image into a new window. 

(4) To Exit 

Any window may be deleted by pressing <Ctrl-C> or <ESC>. If you 
delete the control panel window in this fashion, the program will exit. 

The software for nv was written at Xerox PARC by Ron Frederick and is available 
from ftp://parcftp.xerox.com:/pub/net-research/nvbin-*. (Handley) 
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Figure 5. nv Control Panel 


3. Visual Audio Tool ( vat ^ version 2.4 : Used for audio teleconferences. When a 
session that involves audio communications is selected from the session directory, the vat 
window appears. It is not necessary to speak in order to participate in a conference. In fact, 
the normal etiquette is to wait until the speaker has finished and has opened questions to the 
floor or to the Internet, before speaking. Using vat requires a certain amount of prudence to 
avoid accidental transmissions during conference sessions. The vat window is divided into 
two parts: the right has controls for the local audio and the left side displays the user names 
of those individuals participating in the current session (see figure 6). 
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Figure 6. val window 


The audio controls consist of two sliders that control the microphone and speaker. 
To adjust the shders, either click at the desired position or click and drag the slide button to 
the desired position. Just to the left of each slider is a VU meter. A rule of thumb is to adjust 
the mike and speaker gain sliders so the peak readings on the meter are about 80% of ilill 
scale. Audio input has two forms: microphone and line-in mode. The microphone is normally 
used for desktop conferencing while the line-in mode works best for room conferencing. 
Above the speaker and microphone buttons is a button to mute/unmute either the mike or 
speaker which will mute out sound when depressed. The button will be highlighted when 
muting. Clicking on the microphone icon will toggle input selection to the next auxiliary input 
jack. Clicking on the speaker icon is an alternate way to mute. It is usually a good idea to 
practice getting your audio levels right with someone else remote. 

The left side of the vat window, which lists every site currently participating in the 
session, will always list your site first. The participant name is displayed in a box that is 
highlighted whenever that site is speaking and grayed-out if the participant is no longer 
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connected. This usually indicates that the site has lost connectivity or that vat has been 
aborted or stopped. 

There is a box to the left of each participant name. Clicking on the box puts an ‘x’ 
in it and will cause audio fi-om that participant to be discarded instead of played (for example, 
this might be used to suppress a site that is 
generating echoes). A small black box 
inside each box indicates people who have 
spoken recently. Names, by default, 
appear in the form user@host, but can be 
changed by the user from within the vat 
menu. At the bottom of the vat window 
are four more buttons: 

(1) Keep Audio 

One host can run a 
number of vat sessions. However, since 
most workstations have only one set of 
audio hardware, only one of those sessions 
will be able to access the microphone and 
speaker, If you press the Keep Audio 
button, the audio device will be acquired 
by that session and the session that 
previously held the audio will relinquish it. 

The active session will have the Keep 
Audio button highhghted. 
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(2) Menu 


Clicking on the menu label at the bottom of the vat window will cause 
a panel of auxiliary controls to open (see figure 7). In general preset defaults should be used; 
however you have the option of adjusting these controls. The Audio Tests buttons will 
generate audio test tones to verify software and your audio hardware are properly 
configured. Loopback lets you speak into the microphone and hear your voice locally. Be 
careful not to cause feedback. These should never be selected during a conference. No 
Silence Suppress, located in Output Mode, should be selected for noninteractive sessions at 
the transmitting she. This may result in better quahty audio by using longer playout periods. 
Conference mode, located in Network portion of the Menu, is recommended for interactive 
sessions. Lecture mode should be chosen for noninteractive sessions. The switch can be 
made at any time and takes effect immediately. 

There are two type-in boxes at the bottom of the Menu. The one labeled 
Name can be used to change the session name announced to other shes. The one labeled Title 
can be used to change the title of your session. Go ahead and be creative! Modifying the title 
is an excellent way to pass messages during an audio program that is continuously originating 
from a single source. The Key button can be used to specify an encryption key. Since vat 
conversations are typically conducted over open IP networks there is no way to prevent 
eavesdropping, particularly for muhicast conferences. To add some measure of privacy, vat 
allows the audio packet streams to be DES encrypted. The Dismiss button will return you 
back to the main vat window. 

(3) Help. This button provides more detailed information about vat. 

(4) Quit. Selecting this button will end the va/session. 

The vat software was written by Van Jacobson and Steve McCanne of LBL, with 
contributed effort from others, and is available fi'om ftp://ftp.ee.lbl.gov:/conferencing/vat/ 
(Handley). 
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4. Video Conference ( v/cV vie is an experimental video conferencing tool for 
transmitting video over an IP Multicast network. The main vie window provides an 
abbreviated summary of all sources that are actively transmitting video to the conference 
address (see figure 8). If no one is transmitting video to the session, the text ‘No Network 
Sources’ will be displayed. 

Clicking on the Menu button in the lower right hand comer of the main vie window 
will bring up vie menu (see figure 9), which is composed of three subpanels: Transmission, 
Encoder, and Session. 



The Transmission subpanel includes a Transmit button which opens the video captiue 
device and begins transmission. The Lock button is designed to prevent any external agents 
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from automatically initiating or terminating transmission. The Release button will terminate 
the transmission if active and close the capture device. Adjacent to the transmission buttons 
are Rate Control sliders. The bit rate is limited by the top slider while the frame rate is limited 
by the bottom slider. The frame rate slider ranges from 1 to 30 frames/sec, while the bit-rate 
slider ranges from 10 to 3072 Kbps, The actual capture (and encode) rates can vary within 
these bounds and are displayed above the two sliders. 

The Encoder subpanel contains controls for selecting the coding format, video image 
size, coding quality level, device ports, signal type, and device. Not all options are supported 
by all devices. Formats that are not supported by the underlying device (or by software 
compression) are grayed out and disabled. The video image size is controlled by selecting 
generic ‘small’, ‘normal’ and ‘large’ formats. If a size is not supported by the underlying 
hardware, the corresponding button will be disabled. The Port button selects among the 
analog input jacks to the capture device for example, a VideoPix has two composite inputs 
and an S-Video input. The Type button selects the analog video types, which is one of auto, 
NTSC, PAL, or SECAM. The ‘auto’ setting attempts to determine the signal type from the 
actual input. 

The Session subpanel controls conference address information, some type-in boxes, 
and other session controls. The first line of the panel lists the numeric IP address, UDP port 
of the conference, the RTP source identifier, and the multicast ttl. The type-in box labeled 
Name can be used to change the RTP session name aimounced to other sites. The other type- 
in box labeled Key contains an optional session key for encryption. (Since vie conversations 
are typically conducted over open IP networks, there is no way to prevent eavesdropping, 
particularly for multicast conferences. Below the type-in boxes are switches for controlling 
session behavior. The Mute New Sources button, when selected, causes sources that transmit 
video to come up ‘muted.’ 

Along the bottom of the control menu you will find a Tile button. This is a pull-down 
menu that allows you to specify the number of columns to use for displaying the thumbnail 
summaries of each active source. The default is single column. The number of columns can 
also be specified by typing a single digit into the main window. Also along the bottom is a 
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Members buRon that brings up a top level window with a scrollable list of all the participants 
in the session. This list includes partic^ants that are not actively sending video. The Dismiss 
buRon will close the menu. 

Once you have made all your selections in the menu and are ready to send, click the 
Transmit buRon. A small video image will appear in the vie main window (see figure 10). 
If other participants decide to transmit over the same session, their video images will appear 
in the window as well For each video source the vie window will display identification text, 
some bit and fi-ame rate statistics, a Mute buRon, a Color buRon, a Stats buRon as well as the 
small video image. 

The Mute buRon, when selected, causes vie to ignore video fi'om the corresponding 
host. In general, you want to disable any site you're not interested in to reduce processor 
load. The Color buRon controls the color disposition of the output. When enabled (by 
de&uh), video is displayed in color; otherwise, it is displayed in grayscale. The Stats buRon 
brings up a top level window containing network and video coding statistics for the 
corresponding source. These statistics are updated in real-time once per second. 



Figure 10 v/c window with video icon 
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Left-mouse button clicking on a video image will open a larger viewing window of 
the participating source (see figure 11). Along the bottom of the window is a Size button 
used to set the window size and a Dismiss button to close the window. The Mode button 
changes the switching mode of the window. By default, the switching mode is ‘locked”, 
which means that the window is locked onto the indicated video source. In ‘Itrowse” mode, 
you can cycle through the participants by hand using the *>’ and ‘<' keys. 
vie was developed by Van Jacobson and Steve McCanne at LBL. 



Figure 11. vie video icon 

5. Shared whi t eboard ( wb ) tool : Figure 12 is a picture of the whiteboard tool. 
Whiteboard can be used as a shared drawing surface and it can be used to export and view 
small PostScript files. Speakers can make their slides available as PostScript files during a 
conference session. The camera can be directed at the speaker while the sUdes are viewed via 
the whfteboard facility. Take some time to learn this tool. At first, set up a test session with 
a ttl of 1. 

The software was written at LBL by Van Jacobson and Steve McCanne and is 
available fi'om ftp://ftp.ee.lbl.gov:/conferencing/wb/*-wb.tar.Z (Handley) 
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Figure 12. Whiteboard tool (wft) 

D. HARDWARE REQUIREMENTS 

No special hardware is required to receive video on the MBone. Decoding and 
di^lay are all done in software using an X-window display. The data rate is typically 25 Kbps 
to 128 Kbps. Transmitting video requires a workstation with a frame-capture board and 
camera, typically a camcorder with a video output or built-in camera. Several different boards 
are supported, including Sun’s SunVideo, SGI’s IndigoVideo, and the Sony NEWS frame 
capture board. 

To receive audio, a machine must be audio equipped such as the SunSparclO with an 
audio box, some Hewlett-Packard workstations, the SGI Indy and SGI Indigo. On most 
architectures, no hardware other than a microphone is required - sound I/O is via the built-in 
audio hardware. 

E. OTHER REQUIREMENTS 

1. Good lighting: Given a choice between office lighting and a desk lamp, the lamp 
significantly improves image quality, especially in otherwise low light conditions with 
inexpensive cameras. 
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2. Video camera: If you will be transmitting video, a fixed focus camera that works 
well in your particular lighting conditions is fine for the desktop. A camcorder is more 
expensive, but performs better in lower light and has zoom capability. Once again, a camera 
isn’t required to receive or display video. 

F. POPULAR EVENTS 

Many things are broadcast over MBone, including NASA Select's coverage of shuttle 
missions. The House and Senate usually broadcast audio sessions, and Radio Free Vat is a 
‘radio-station’ where any MBone participant can sign up for spots to play music. Scheduling 
events is very iirqjortant, especially if they are to be transmitted on a global chaimel. Events 
can be announced by sending a message to the MBone mailing list called rem-conf@es.net 
and also by using the online MBone Global Agenda located at 
http:/Avww. cilea. it/MBone/agenda. html. 

G. MAP OF THE MBONE 

A small map of the MBone can be found at 
ftp://parcftp. xerox, com/pub/net-research/mbone-map-small.ps 
A large map can be found at 

ftp://parcftp.xerox.com/pub/net-research/mbone-map-big.ps 

H. NETWORK CONSIDERATIONS 

Multicasting is bandwidth eflScient as one packet can be received by all machines on 
a network. For example one audio stream received by one workstation uses the same 
bandwidth as the same stream being subscribed to by 15 workstations. Another good feature 
of the MBone is that the life of a session can be limited, for example a broadcast may be set 
to last 30 minutes. After that time the broadcast ends and the resources are recouped for new 
sessions. 

Another good feature is that the packets may be limi ted in their transmission radius. 
There is a ff/ (time to live) setting that is used to limit how far a packet might go. For example 
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a university might want to limit a transmission from a general student machine to campus 
machines only, this would be accomplished by a ttl setting of 16. This can happen because the 
ttl field is decreased each time the packet is sent through an mrouter. This limiting ability is 
important because transmissions such as video can use much of the resources of the 
connections between sites on the Internet. Audio usually consumes 32 or up to 64 Kbps and 
defauh video twice that at 128 Kbps. This number is based on the encoding method selected 
in the vai window. Video multicasts should have lower ttl setting so they do not pass through 
links with low bandwidth. 

L DO’S & DON’TS 

There are no formal procedures for scheduling the use of the MB one, at least not yet. 
Management of bandwidth is a cooperative effort depending on the good behavior of the 
participants. Using the MBone without any regard to other users (i.e. broadcasting at high 
amounts of bandwidth) is not only rude but can bring a great deal of embarrassment to 
yourselfas well asNPS. Please use common sense, ff done properly, using the MBone can 
be fim. 

Typically, discussion of the use of the MBone happens on the rem-conJ@es.net 
mailing list. To subscribe to this list, send a message to rem-conf-request@es.net. Many 
events are annoimced by a message to rem-conf The following are some guidelines to 
consider when planning an MBone session: 

(1) Realize that the MBone is ejqrerimental so make sure you understand the 
fundamentals of the technology. 

(2) Try a couple of test sessions at a ff/ of 1. You won’t bother anyone with this and 
you’ll learn the tools and can even use a higher bandwidth (say 256 Kbps). 

(3) Read the man pages for the MBone tools! They go into greater detail. 

(4) Announce any session over a ttl of 16 ahead of time to rem-conf@es.net 

(5) Don’t leave your Mute button off while in vat. No one else will be able to talk 
to you! This is a frequent (and embarrassing) error made by begiimers. 
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(6) Check your microphone & speaker levels in vat. They should be at approximately 
80%. You don’t want to blast out remote Usteners. Get confirmation on audio levels from 
remote Usteners. 

(7) If broadcasting a noninteractive session, it is a good idea to get status reports 
from remote sites. Coordinate volunteers and be nice to them — they are doing you a favor. 

(8) Use the diagnostic tools that come with the MBone tools. Watch packet loss as 
an indicator that something is wrong. 

(9) There are a few diagnostic tools like tcpdump that are designed to identify 
network problems, e.g. bad icmp messages, igmp messages, etc. At a minimum they help to 
see if packets are even on the net. Take some time to learn about these tools and use them 
for your major broadcasts. 

(10) Conceivably a remote user may somehow gain access to your workstation. The 
only certain way to prevent unauthorized eavesdropping is to physicaUy cover (disconnect) 
the camera and physically disconnect the microphone. 

J. FLIRTHER CVFORMATION 

The information contained in this guide was obtained from the following resources. 
For a more comprehensive understanding of the MBone and associated tools, please take a 
look at these. 

1. MBone Provides Audio and Video Across the Internet, IEEE Computer 
magazine, April 1994. ftp://taurus.cs.nps.navy.mil/pub/i3la/mbone.html 

2. Introductory description of MBone (draft) from MICE. 

3. The MBone Information Web. http://www.eit.com/techinfo/mbone/mbone.html 

4. Dan's Quick and Dirty Guide to Getting Connected to the MBone 

5. Guide to MBone etiquette, http://www.eit.com/techtnfo/mbone/etiquette.html 

6. The MBone FAQ. http://www.research.att.com/MBone-faq.html 

7. Unix Man pages on vat, nv and vie. 

8. The MBone maiUng Ust - subscribe to; MBone-request@jsi.edu 
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K. ACCESSING THE MBone TOOLS 

The MBone can only be accessed through Unix workstations at this time. Labs at the 
Naval Postgraduate School that currently support the MBone include: 

1. IneersoU Hall : Visualization Lab (VisLab room 148) 

Any person who has a Computing Services Unix account and has received MBone 
training may receive execute permissions to use the MBone tools. See Larry Frazier (rm In- 
113) for training and more information. 

2. Root Hall : Systems Technology Lab (STL room 204) 

Any person with an account in this lab automatically has execute permissions to use 
the MBone tools. See Milena Cochran (room 204) for more information. 

3. Halligan Hall : Aero Lab (room 103D) 

Any person with an account in this lab automatically has execute permissions to use 
the MBone tools. See Tony Cricelli (room 134) for more information. 

4. Melville Hall : Mechanical Engineering Lab (room 138) 

Any person with an account in this lab automatically has execute permissions to use 
the MBone tools. The MBone tools are only available on a few machines in this lab. See 
Dave Marco (room 138A) for more information. 

5. Spanagel Hall : Virtual Reality Lab (room 506) 

Any person who has an account in this lab and has received training may receive 
execute permissions to use the MBone tools. See Susan Whalen (room 525B) or Rosalie 
Johnson (room 527B) for more information. 

6. Glasgow Hall : 

The MBone tools are not available in Glasgow. 

L. LOGIN PROCEDURES 
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For information about using Unix see your local support office or take a look at the 
Scientific Visualization Laboratory User’s Guide (Chap 2, sec 2). It can be found online at 
http ://www. nps. navy, mtl/vislab/userdoc 

M. POINTS OF CONTACT 

For User problems please check with one of the following: 

1. IngersoU: 

- Larry Frazier room 113 (x2671) 

- Mike McCann room 102B (x2752) 

- Matthew Koebbe room 102A (x3778) 

2. Spanagel: 

- Rosalie Johnson room 527B (x3392) 

- Susan Whalen room 525B (x2967) 

3. Root: 

- Milena Cochran room 204 (x1120) 

- James Schmidt room 205B (x3674) 

4. Halligan: 

- Tony Cricelli room 134 (x2910) 

5. Melville: 

- Dave Marco room 138A (x2809) 
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APPENDIX B: ACRONYMS 


ACM Association for Computing Machinery 

AI Artificial Intelligence 

AV Audio Visual 

CAI Computer Aided Instruction 

CNET Chief of Naval Education and Training 

DFAS Defense Finance and Accounting Service 

DoD Department of Defense 

E-mail Electronic Mail 

FAQ Frequently Asked Questions 

FDDl Fiber Distributed Data Interface 

FPS Frames Per Second 

FTP File Transfer Protocol 

GMT Greenwich Mean Time 

ICMP Internet Control Management Protocol 

IETF Internet Engineering Task Force 

DRG Information Infi'astructure Research Group 

IP Internet Protocol 

Kbps Kilobits per second 

LAN Local Area Network 

MBone Multicast Backbone 

Mbps Megabits per second 

MICE Multimedia Integrated Conferencing for Europe 

Mrouter Multicast Router 

NPS Naval Postgraduate School 

NTSC National Television Standards Committee 

NV Network Video 

ONT Oflfice of Naval Technology 
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PC Personal Computer 

SD Session Directory 

SGI Silicon Graphics Incorporated 

SIGGRAPH Special Interest Group on Graphics 

TAD Temporary Active Duty 

TCP Transport Control Protocol 

TTL time to live 

UDP User Datagram Protocol 

URL Uniform Resource Locator 

VCR Video Cassette Recorder 

WAN Wide Area Network 

WB Whiteboard 

WWW World Wide Web 

VAT Visual Audio Tool 

VIC Video Conference 

VTC Video Teleconferencing 

VTT Video Teletraining 
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APPENDIX C: GLOSSARY 


Bandwidth . A measure of the amount of data that can be transmitted per unit of time. 
The greater the bandwidth, the higher the possible data transmission rate. 

Broadca.sting . One host sends to all hosts on the same subnet. 

CU-SeeMe . A video/audio conferencing application that runs on PCS and Macintosh 
computers. 

Data Communications . The transmission of data to and from computers and components 
of computer systems. 

Data Rate . The amount of information that can be transmitted per unit of time. 

Distance learning . Communication between an instructor and student via some form of 
telecommunications. 

File Transfer Protocol iFTPV The standard protocol for transferring files between 
machines on the Internet. 

Information Infrastructure Research Group . 

Internet . The global collective of interconnected computer networks, typically those that 
communicate using TCP/IP. 

Internet Control Message Protocol (ICMPI . 

Internet Protocol IIPI . Routes data packets between networks. 

Local Area Network (LANI . A communications network in which all of the components 
are located within several kilometers of each other and which uses high transmission 
speeds - generally one milli on bits per second or higher. 

Multica.st Backbone . A virtual network that provides many-to-many network delivery 
services for applications such as videoconferencing and audio where several hosts need to 
communicate simultaneously. 

Multica.sting . The ability of an application to send a single message to the network and 
have it delivered to multiple recipients at possibly different locations. 
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Network . Two or more computers connected via a communications medium, together 
with all communications, hardware, and, software components. Alternatively, a host 
processor, together with its attached terminals, workstations, and communications 
equipment, for example, transmission media, modems, and so on. 

Network Video tool . A tool used to transmit and receive slow frame rate video. 

Session Directory . A tool used to manage MBone sessions. 

Shared whiteboard tool . A shared white board drawing surface that can be used to export 
and view postscript files. 

Time To Live ( ttr\. A counter used to limit multicast packet lifetimes. A threshold that a 
multicast datagram needs to be forwarded onto a given tunnel. 

Transport Control Protocol ITCPV Provides end-to-end delivery services, reliability and 
error control. 

Unicasting . One host is sending to another specific single host. 

User Datagram Protocol lUDPV A connectionless transport protocol that allows users to 
send messages without connection establishment and without any guarantee of delivery 
service or sequencing. UDP is simply a user interface to EP. 

Video Conference . An experimental video conferencing tool for transmitting video over 
an IP Multicast network. 

Video teleconferencing . A two-way electronic form of communications that permits two 
or more people in different locations to engage in face-to-face audio and visual 
communication. Meetings, seminars, and conferences are conducted as if all participants 
are in the same room. 

Video teletraining . The use of teleconferencing point-to-point or multi-point to provide 
interactive remote site training. 

Vi.sual Audio Tool . A tool used for audio teleconferences. 

World Wide Web . The initiative to create a universal, hypermedia-based method of access 
to information. It is also a client-server based service that runs over the Internet. Also 
called webspace in another sense. 
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